1. Field of the Invention
The present invention relates to computer systems with novel input-output (I/O) architectures, and more particularly, and not by way of limitation, to systems for hiding peripheral devices connected to a bus from the host operating system and associated host processor.
2. Description of Related Art
A conventional computer system typically includes one or more central processing units (CPUs) capable of executing algorithms and one or more memory subsystems. Computer systems also include peripheral devices, or, peripherals, for inputting and outputting data. Some common peripheral devices include, for example, monitors, keyboards, printers, modems, hard disk drives, floppy disk drives, and network controllers. As known in the art, peripheral devices may be conveniently categorized into several classes based on their functionality. For example, the xe2x80x9cblock storage devicexe2x80x9d class of peripherals may include hard disk drives, whereas the xe2x80x9cLocal Area Network (LAN) portsxe2x80x9d class may include LAN controllers, such as, for example, Ethernet controllers. The various components of a computer system communicate and transfer data using a bus system which is connected to the communicating components.
One of the key factors in the performance of a computer system is the speed at which the CPU operates. Generally, the faster the CPU operates, the faster the computer system can complete a designated task. Another method of increasing the speed of a computer system is using multiple CPUs, commonly known as multi-processing. With multiple CPUs, algorithms required to complete a task can be executed substantially in parallel as opposed to their sequential execution.
However, the addition of a faster CPU or additional CPUs can result in different increases in performance among different computer systems. Although it is the CPU that executes the algorithms required for performing a designated task, in many cases, it is the peripherals that are responsible for providing data to the CPU and storing or outputting the processed data from the CPU. When a CPU in operation attempts to read or write to a peripheral, the CPU often xe2x80x9csets asidexe2x80x9d the algorithm which it is currently executing and is diverted to executing the read/write transaction (also referred to as an Input/Output transaction, or an I/O transaction) for the peripheral. As can be appreciated by those skilled in the art, the length of time that the CPU is diverted is typically dependent on the efficiency of the I/O transaction.
Although a faster CPU may accelerate the execution of an algorithm, a slow or inefficient I/O transaction process associated therewith would create a bottleneck in the overall performance of the computer system. As the CPU becomes faster, the amount of time executing algorithms becomes less of a limiting factor compared to the time expended in performing an I/O transaction. Accordingly, the improvement in the performance of the computer system that could theoretically result from the use of a faster CPU or the addition of another CPU may become substantially curtailed by the bottleneck created by I/O transactions. Moreover, it can be readily appreciated that any performance degradation due to such I/O bottlenecks in a single computer system may have a stifling effect on the overall performance of a computer network in which the computer system is disposed.
Operating peripheral devices in association with a computer system typically requires a piece of executable code, known commonly as a device driver. Because peripherals are often manufactured separately from the CPU, the operation of a peripheral is generally effectuated by a unique device driver associated with the specific peripheral. The device driver, which controls the peripheral, is an executable computer program that is executed by the CPU and must be compatible with the particular operating system (OS) of the computer system. It can be readily seen that because device drivers are unique to both operating systems as well as peripherals, a considerable number of device drivers are typically required to support the numerous possible combinations of peripherals and operating systems. Accordingly, it can be appreciated that the ensuing device driver proliferation thwarts the objective of device driver portability in the design of cross-platform computer system architectures.
Based on the foregoing discussion, it should be appreciated that current computer systems with a conventional I/O architecture utilizing device drivers described above suffer from a lack of device driver portability and performance constraints due to I/O bottlenecks. In order to address these shortcomings, an alternative I/O architecturexe2x80x94commonly known as the Intelligent Input/Output (I2O) architecturexe2x80x94has been developed in the computer industry. Because the teachings of the present invention may be better described in relation to the I2O architecture, a brief overview thereof is provided hereinbelow.
The I2O architecture uses a xe2x80x9csplit driverxe2x80x9d model which inserts a messaging layer between the portion of the device driver specific to the operating system and the portion of the device driver specific to the peripheral. The messaging layer splits the single device driver of today into two separate modulesxe2x80x94an Operating System Service Module (OSM) and a Downloadable Driver Module (DDM). The only interaction one module has with another module is through this messaging layer which provides the communication means.
The OSM comprises the portion of the device driver that is specific to the operating system. The OSM interfaces with the operating system of the computer system (which may also be referred to in the art as the xe2x80x9chost operating systemxe2x80x9d) and is executed by the host CPU or processor. Typically, a single OSM may be used to service a specific class of peripherals. For example, one OSM would be used to service all block storage devices, such as hard disk drives and CD-ROM drives. The DDM provides the peripheral-specific portion of the device driver that understands how to interface to the particular peripheral hardware. To execute the DDM, an I2O Input/Output Processor (IOP) is added to the computer system. A single IOP may be associated with multiple peripherals, each controlled by a particular DDM, and containing its own operating system such as, for example, the I2O Real-Time Operating System (iRTOS). The DDM directly controls the peripheral, and is executed by the IOP under the management of the iRTOS.
Those skilled in the art will recognize that a DDM may typically comprise a Hardware Device Module (HDM) that directly interfaces with the peripheral and is responsible for its control and data transfer associated therewith. DDMs can also comprise an Intermediate Service Module (ISM) which is an additional software interface to the HDM. The ISM is often used for filtering, encoding, and decoding messages to the HDM.
In general operation, the communication model used in the I2O architecture is a message passing system. When the CPU seeks to read or write to a peripheral in an I2O system, the host operating system makes what is known as a xe2x80x9crequestxe2x80x9d. The OSM translates the request by the host operating system and, in turn, generates a message. The OSM sends the message across the messaging layer to the DDM associated with the peripheral which processes it appropriately to achieve a result. Upon completion of the processing, the DDM sends the result back to the OSM by sending an appropriate message through the messaging layer. It can be appreciated that to the host operating system, the OSM appears just like any other device driver.
By executing the DDM on the IOP, the time-consuming portion of transferring information from and to the peripheral hardware is off-loaded from the CPU to the IOP. With this off-loading, the CPU is no longer diverted for inordinate amounts of time during an I/O transaction. Moreover, because the IOP is a hardware component essentially dedicated to the processing of the I/O transactions, the problem of I/O bottlenecks is mitigated.
The I2O architecture also significantly reduces the number of device drivers written on the basis of the split driver model. Typically, peripheral device manufacturers need only write a single DDM for a particular peripheral which can now operate with any host operating system. The vendors of the host operating system need only write one OSM for each class of peripherals, e.g., the network controller class.
One of the goals of the I2O architecture is to allow standard xe2x80x9cnon-intelligentxe2x80x9d or xe2x80x9csemi-intelligentxe2x80x9d peripheral devices to be controlled by a generic I2O IOP resource (for example, an I2O xe2x80x9cacceleratorxe2x80x9d card) that could be added to a computing system. If the IOP contains the necessary software to control a particular peripheral device, the device may be abstracted through the IOP to xe2x80x9clookxe2x80x9d like an intelligent I2O peripheral. However, it may be appreciated that in order to incorporate the I2O technology in a computer system and realize the benefits afforded thereby, host processors and operating systems need to be able to differentiate between peripheral devices that are subordinate to the IOP resource (that is, peripherals under the control of the I/O processor) and peripheral devices that are not (that is, xe2x80x9csystemxe2x80x9d or xe2x80x9cpublicxe2x80x9d peripherals under the control of the host processor/s). Although system software that is I2O-compliant is typically capable of making this distinction, legacy software, i.e., software developed and deployed prior to the development of the I2O architecture or which is otherwise not I2O-compliant, on the other hand, usually cannot make this distinction. Therefore, to retain the investment made in the legacy software through its continued use while at the same time realizing the benefits of the I2O technology, there has arisen a substantial need for schemes whereby subordinate peripheral devices are rendered xe2x80x9cinvisiblexe2x80x9d or xe2x80x9chiddenxe2x80x9d from host processors and host operating systems.
One of the current methods used for hiding peripheral devices involves the use of a bus-to-bus bridge, for example, a bridge device coupling two buses, such as the Peripheral Component Interconnect (PCI) buses, and a private address space allocation mechanism used by a particular IOP that is common in the industry. Devices under the control of the IOP are hidden from the host processors and their related software by placing these devices behind the PCI-to-PCI bridge and allocating memory address space to the down-stream PCI bus for address information pertaining to them. The allocated memory address space is inaccessible by the host processors and, thus, the peripheral devices are rendered invisible thereto.
Another method of hiding peripheral devices involves the use of certain switching devices (for example, components known in the industry as xe2x80x9cquick switchesxe2x80x9d). The switching devices may be employed under the control of an I2O accelerator card having an I/O processor thereon for blocking a PCI signal line (Initialization Device Select or IDSEL signal) that is used as a xe2x80x9cchip selectxe2x80x9d signal for the peripheral devices during their configuration. The firmware running on the I2O accelerator undertakes a decision making process as to when the IDSEL signal is to be asserted for a particular subordinate peripheral device.
Solutions, such as those described hereinabove, for hiding peripheral devices from host processors have various deficiencies and shortcomings. For example, one approach requires a PCI-PCI bridge and the use of a particular type of IOP with its private address space allocation mechanism. Also, in this approach, it is required that the devices be placed down-stream from the PCI-PCI bridge for hiding them. The static xe2x80x9cquick switchxe2x80x9d approach, on the other hand, suffers from the risk of xe2x80x9cinappropriatexe2x80x9d timing of the blocking and unblocking of the IDSEL signals by the I2O accelerator card. Typically, the I2O accelerator firmware sets a xe2x80x9cmaskingxe2x80x9d bit corresponding to a particular subordinate device, which masking bit then masks an enable signalxe2x80x94IDSEL ENABLExe2x80x94therefor, thereby causing the device""s IDSEL signal to be deasserted. Subsequently, when the I2O accelerator wants to communicate to the subordinate device, it negates the mask by clearing the appropriate bit, thereby causing the corresponding IDSEL ENABLE signal to be asserted. It is possible that when the I2O accelerator unblocks a particular IDSEL signal for a corresponding subordinate device, another bus masterxe2x80x94including a host processor under the host OSxe2x80x94may gain control of the bus and attempt to access the subordinate peripheral device. It can be appreciated that such an attempt to access the subordinate device by the host processor may yield undesirable results.
The present invention overcomes the above-identified problems as well as other shortcomings and deficiencies of the existing technology by providing a system wherein the goal of hiding the subordinate peripheral devices from the host processor/s and host operating systems is achieved by determining when a host-associated bus transaction is about to be effectuated on a bus to which the subordinate devices are coupled. Preferably, the determination is made on the basis of one or more bus signals supplied to a dynamic device blocker module. Responsive to the determination, switching devices are selectively actuated based on a list of which peripherals are to be hidden.
Accordingly, the present invention is directed in one aspect to a computer system having a host processor, a processor bus and a host operating system executing on the host processor, comprising: a plurality of peripheral devices coupled to an input/output (I/O) bus that is, in turn, coupled to the processor bus via a host-to-bus bridge; and a device blocker module for receiving a plurality of bus signals associated with the I/O bus, wherein the device blocker module, based on the plurality of bus signals, hides at least a portion of the plurality of peripheral devices from at least one of the host processor and the operating system.
In another aspect, the present invention is directed to a computer system, comprising: at least one host processor for executing a host operating system, the host processor disposed on a host bus; a first input/output (I/O) bus operably coupled to the host bus via a host-to-bus bridge, which first I/O bus for propagating at least one of a FRAME signal, a GRANT signal, an IRDY signal and a clock signal associated therewith; a plurality of peripheral devices operably connected to the first I/O bus; a dynamic device blocker module disposed on the I/O bus for rendering at least a portion of the plurality of peripheral devices hidden from the host operating system based on at least one of the FRAME signal, the GRANT signal, the IRDY signal and the clock signal associated therewith; and an accelerator module disposed on the I/O bus for controlling the portion of plurality of peripheral devices hidden thereby.
The present invention is also drawn to a method of hiding a subordinate peripheral device disposed on an input/output (I/O) bus from a host processor and its software in a computer system, which computer system includes a host-to-bus bridge for coupling between the I/O bus and a host bus, and an I/O processor, comprising the steps of: monitoring one or more bus signals associated with the I/O bus; and based on the bus signals, selectively blocking or unblocking for a period of time an IDSEL signal associated with the subordinate peripheral device.